Skip to content

chore: add optional shared registry image push - #44

Merged
muhammad-tahir-nawaz merged 3 commits into
prodfrom
feat/shared-registry-push-workflow
Jul 28, 2026
Merged

chore: add optional shared registry image push#44
muhammad-tahir-nawaz merged 3 commits into
prodfrom
feat/shared-registry-push-workflow

Conversation

@muhammad-tahir-nawaz

Copy link
Copy Markdown
Contributor

Summary

Adds an optional push of each service image to the shared GCP project, so the operator being developed in wanaware-operator has the images it needs to pull and run.

This is an alternative to #43. Same goal, but structured so it is strictly additive and cannot affect any existing deployment.

  • New workflow .github/workflows/shared-registry-push.yaml — standalone reusable workflow. Authenticates to the shared project only, builds the image, pushes to the shared registry.
  • deployment.yaml — one new job (push-to-shared-registry) that calls it, plus four new optional secret declarations. 48 insertions, 0 deletions — no existing line is changed or moved.

Isolation, concretely:

  • Runs as its own job on its own runner, so its gcloud credentials and docker credential helper cannot leak into the deploy job.
  • Only ever authenticates to the shared project — it never touches the WanAware registry, so it cannot disturb existing auth.
  • continue-on-error at both step and job level, so a failure here can never turn a deploy run red.
  • Skips cleanly when the shared secrets are absent, so repos that have not onboarded see no failed steps.

Callers need no changes. The shared push activates purely by setting the four GCP_*_SHARED secrets on a repo.

It rebuilds from source rather than retagging the deploy job's image, because that image is only loaded into the deploy runner's local docker daemon; pulling it instead would mean authenticating to the WanAware registry from this job, which is exactly the coupling this design avoids. The build uses the same context, Dockerfile and build-args, so the image matches what deployment.yaml ships.

Why

Required so the wanaware-operator has permission to pull and run the images. Supersedes #43, which reordered the existing auth steps — that made the build run before any GCP auth, which would break builds using a private base image from GAR.

QA Report

  • No QA report required

CI/workflow-only change with no user-facing API surface.

Integration Tests

  • No integration tests required

Added

Edited

Dependencies

Four new optional GitHub Actions secrets, per repo that should publish to the shared registry:

  • GCP_SERVICE_ACCOUNT_SHARED
  • GCP_WORKLOAD_IDENTITY_PROVIDER_SHARED
  • GCP_PROJECT_SHARED
  • GCP_REGISTRY_SHARED

All optional. Without them the shared push is skipped and behaviour is unchanged.

Notes for Reviewer

The new job pins the called workflow with @prod, matching the existing convention for WanAware/.github references. That means the shared push only becomes live once this is merged to prod.

Adds a standalone reusable workflow that builds the service image and pushes
it to the shared GCP project so the wanaware-operator can pull and run it.

Triggered as a separate job from deployment.yaml so callers need no changes.
The job is fully isolated from the deploy path: it runs on its own runner,
only ever authenticates to the shared project, and is continue-on-error at
both step and job level, so it cannot affect existing deployments.

Activates only when the four GCP_*_SHARED secrets are set; otherwise it
skips cleanly.
Comment thread .github/workflows/deployment.yaml
@greptile-apps

greptile-apps Bot commented Jul 28, 2026

Copy link
Copy Markdown

Greptile Summary

Adds an optional, isolated workflow for publishing service images to a shared GCP registry.

  • Declares four optional shared-project credentials in the reusable deployment workflow.
  • Adds a separate post-deployment job that invokes the shared-registry workflow.
  • Builds the triggering revision and publishes it under the shared registry's latest tag.
  • Reports shared-push failures as workflow warnings without failing the deployment run.

Confidence Score: 2/5

The PR is not safe to merge until a failed primary deployment can no longer publish its rejected revision as the shared registry's latest image.

The shared job still runs under always() after the deploy job fails, checks out the same triggering revision, and independently pushes it as latest, so the operator can consume an image that the primary pipeline did not successfully deploy.

Files Needing Attention: .github/workflows/deployment.yaml and .github/workflows/shared-registry-push.yaml

Important Files Changed

Filename Overview
.github/workflows/deployment.yaml Adds optional shared-registry secrets and a post-deployment reusable-workflow job.
.github/workflows/shared-registry-push.yaml Adds the reusable workflow that authenticates to the shared project, rebuilds the service image, pushes latest, and reports failures non-fatally.

Reviews (3): Last reviewed commit: "chore: restore prod pin and surface shar..." | Re-trigger Greptile

Reverts the temporary feature-branch pin used for end-to-end testing.

Adds a ::warning:: annotation when the shared push fails. The job is
best-effort and stays green so it can never affect a deploy, which meant a
failed push was previously only visible in the run summary.
@muhammad-tahir-nawaz
muhammad-tahir-nawaz merged commit 0be81a3 into prod Jul 28, 2026
3 of 4 checks passed
@muhammad-tahir-nawaz
muhammad-tahir-nawaz deleted the feat/shared-registry-push-workflow branch July 28, 2026 11:36
@scottlee01818 scottlee01818 mentioned this pull request Jul 29, 2026
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants